Method of speeding up the registration procedure in a cellular network

ABSTRACT

A method of carrying an application level message encapsulated inside a signaling message of an access network is described. The method includes receiving an application level message from a sender application process to an access network signaling process, adapting the application level message and encapsulating the application level message in a signaling message of an access network, and delivering the encapsulated application level message to a receiver application process by transmitting the signaling message, The encapsulated application level message is transparent to the devices of the access network transmitting the signaling message.

FIELD OF THE INVENTION

The present invention relates to a method of speeding up theregistration procedure in a cellular network.

PRIOR ART

The current wireless networks need a separate message to manage theconnectivity to an external network, e.g. get connected to the network(PDP context activation), and to register, with a given application,e.g. the Session Initiation Protocol (SIP) register procedure for theVoice over Internet Protocol (VoIP) or instant messaging, etc. Thisimplies that two round trip delays (over the radio distance) minimum areneeded before the application becomes available.

In a cellular network, sending a packet does not only imply the physicaltransmission time of a packet over the radio, but also the time toestablish radio resources. This time can be significant (seconds), as isknown from the live network behavior of General Packet Radio Systems(GPRS).

In addition, in a typical mobile terminal, the Packet Data Protocol(PDP) context is started when an application that may need this PacketData Protocol (PDP) context is started. At this time this applicationalready has the information it needs to register (even if thedestination may be a logical name instead of an IP address).

The following two possibilities serve as examples.

A Packet Data Protocol (PDP) context may be established first, and thenan application level message would be sent which however adds a secondround trip delay over the radio distance.

Another one is to send a Remote Authentication Dial-In User Service(RADIUS) start message from a Gateway GPRS Support Node (GGSN) when aPacket Data Protocol (PDP) context is established. However, this doesnot allow the mobile terminal to send information which is specific toit (the mobile terminal's capabilities; the type of push service wanted;an instant messaging group to join; its signature; application settingsetc.) and requires a pre-configuration of all application servers in theGateway GPRS Support Node (GGSN).

Another important design criteria in a cellular network is to maintainthe access network (e.g. of GPRS type) quite independent from theapplications, so that new applications can be added transparently to theaccess network.

SUMMARY OF THE INVENTION

Therefore, it is an object of the present invention to deal with theproblems of the prior art, and to provide a method of speeding up theregistration procedure in a cellular network.

According to the present invention, this object is solved by providing amethod of carrying an application level message encapsulated inside asignaling message of an access network, said method comprising the stepsof: receiving an application level message from a sender applicationprocess to an access network signaling process; adapting saidapplication level message and encapsulating it in a signaling message ofan access network; and delivering said encapsulated application levelmessage to a receiver application process by transmitting said signalingmessage, wherein said encapsulated application level message istransparent to the means of said access network transmitting saidsignaling message. Advantageous modifications are defined in theappended dependent claims.

Hence one or many encapsulated application level messages are includedin the Packet Data Protocol (PDP) context signaling (e.g. especially inthe activation request), so that if the Packet Data Protocol (PDP)context is accepted, gateway node means (e.g. the Gateway GPRS SupportNode (GGSN)) will send the application level message on behalf of themobile terminal to an application server (e.g. a Proxy Call StateControl Function (P-CSCF); a push proxy server (e.g. WirelessApplication Protocol (WAP) gateway) or an instant messaging server).

In particular, the method according to the present invention allows withonly one round-trip over the radio:

-   -   to establish one Packet Data Protocol (PDP) context and register        in one or more application; or    -   to establish one secondary Packet Data Protocol (PDP) context        and to send a ringing indication to the other party; or    -   to modify a Packet Data Protocol (PDP) context and signal the        Quality-of-Service (QoS) change to the other end; or    -   to deactivate the Packet Data Protocol (PDP) context and        de-register from an application.

The present invention is presently considered to be particularlyapplicable to a Session Initiation Protocol (SIP) signaling, but also toother signaling such as a Resource Reservation Protocol (RSVP)signaling, or to a Point to Point protocol (PPP) signaling.

According to the present invention, the registration procedure ingeneral is speeded up. Moreover, the method according to the presentinvention is especially efficient to speed up a call establishmentprocedure for Voice over IP (VoIP) as it can be applied also when aReal-Time (RT) secondary Packet Data Protocol (PDP) context isestablished.

As a consequence, the delay is reduced. Further, the radio and thebackbone is optimized by reducing the needs for radio signaling andreducing the number of packets sent.

A key feature of the present invention is to maintain logicalindependence between the application layer (e.g. SIP or WAP—WirelessApplication Protocol) and the access layer (e.g. GPRS). Thisindependence is based on the fact that the access layer does not need tounderstand application signaling. It only needs to know how to forwardit. Therefore, any new application could obtain the benefit of thisfunctionality without further changes needed in the access layer.

According to the present invention, the present object is further solvedby providing a system adapted to perform a transmission of anapplication level message encapsulated inside a signaling message of anaccess network, comprising: receiving means adapted to receive anapplication level message from a sender application process to an accessnetwork signaling process; adapting means for encapsulating saidapplication level message in a signaling message of an access network;and delivering means adapted to deliver said encapsulated applicationlevel message to a receiver application processing means.

BRIEF DESCRIPTION OF THE DRAWINGS

Further details of the present invention will become apparent from thefollowing description of the preferred embodiments which is to be takenin conjunction with the appended drawings, in which:

FIG. 1 shows a comparative example illustrating a VoIP signaling basedon existing knowledge depicting a GPRS attach, a signaling for a PacketData Protocol (PDP) context activation, a Proxy Call State ControlFunction (P-CSCF) discovery, and a Session Initiation Protocol (SIP)registration;

FIG. 2 shows another comparative example illustrating a VoIP signalingbased on existing knowledge depicting the signaling foreseen toestablish a call;

FIG. 3 shows a Packet Data Protocol (PDP) context activation accordingto the present invention; and

FIG. 4 shows the encapsulated application level message informationelement according to the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

At first, reference is made to the comparative example depicted in FIGS.1 and 2, illustrating a current view of VoIP signaling based on existingknowledge.

In these figures, DNS denotes a directory name service, and DHCP denotesa dynamic host configuration protocol, while UE denotes a user equipmentsuch as a mobile terminal. Other denotations are explained elsewhere inthe present description.

A rough count reveals a minimum of 25 messages over the radio distanceincluding Radio Resource Control (RRC) messages which are not depictedhere for a mobile terminal UE to fixed phone call, when starting with aturned off mobile terminal UE; and at least 40 messages over the radiodistance for a mobile terminal UE(A) to mobile terminal UE(B) call, ifthe called mobile terminal UE(B) is not Radio Resource Control (RRC)connected.

From this realization, it becomes clear why there is a need to optimizethe delay.

It is remarked that according to the present invention, as will beapparent from the description given below, a gain of four to fivemessages may be obtained over the radio distance, since SessionInitiation Protocol (SIP) registration messages can be embedded in aPacket Data Protocol (PDP) context activation request/response, and“COMET”-/“2000K”-messages can be embedded in step 19 (a secondary PacketData Protocol (PDP) context activation request/response), while theringing messages can be embedded in step 24 (secondary PDP contextactivation request). The details of embedding are described below.

A further gain can be achieved if there is a need to modify the bearer(step 33-38) or if the external resources reservation requires an end toend, i.e. mobile terminal to mobile terminal, signaling based on theResource Reservation Protocol (RSVP).

Next, reference is made to FIG. 3 which shows a Packet Data Protocol(PDP) context activation as a preferred embodiment according to thepresent invention.

Firstly, an application (inside the mobile terminal or in a separatedevice such as a laptop) requests the mobile terminal UE to initiate aPacket Data Protocol (PDP) context activation. In the same time, theapplication provides to the session management stack of the mobileterminal UE (this is the software in charge of activating the PDPcontext) an application level message. This application level messagewhich is to be encapsulated may be a complete message such as a SIPregistration message or a request to establish a WAP session. The mobileterminal UE adds the information provided by the application in anoptional Information Element (IE) which shall be called “encapsulatedapplication level message IE” in the PDP context activation requestmessage. The thus encapsulated application level message is thentransparently forwarded by the Serving GPRS Support Node SGSN to theGGSN in the Create PDP Context Request. Here, the term “transparentlyforwarded” implies that the optional encapsulated application levelmessage information element is copied from one message to the otherwithout being interpreted by the SGSN. This Packet Data Protocol (PDP)context may be a normal PDP context, a signaling PDP context or asecondary PDP context.

Secondly, the Radio Access Bearer (RAB) is set up. It should be notedthat step 2 and 3 may be performed in a different order or even inparallel without modifying the idea of the invention.

Thirdly, the Serving GPRS Support Node SGSN sends the Create PDP ContextRequest message to the selected Gateway GPRS Support Node GGSN.According to the above, also this message includes the optionalencapsulated application level message information element.

When receiving the request, the GGSN will interpret the encapsulatedapplication level message information element. The encapsulatedapplication level message information element indicates whichinformation should be sent to which destination address, i.e. a logicalname or IP address, and under which condition, for example, if thePacket Data Protocol (PDP) context is accepted; if the Packet DataProtocol (PDP) context is accepted with the requested Quality-of-Service(QoS) (Here, the GGSN firstly processes the PDP context requestnormally. If the output is that the PDP context is accepted (with thesame Quality-of-Service in option 2), it sends the application levelmessage forward. If the PDP context is rejected, (or theQulaity-of-Service is modified in option 2) the application levelmessage is then just erased) if the response should be sent immediatelyor only when the application server response is received; etc. If thedestination address is indicated as a logical name (e.g. “SIPproxy” or“WAPgateway”), the GGSN resolves a logical name from its configured data(e.g. Access Point Name (APN) configuration) or by querying theDirectory Name Service DNS system. The GGSN extracts the content fromthe encapsulated application level message and, forwards it, in step 4,to the application server by using information sent in encapsulatedapplication level message information element, and/or information comingfrom the PDP context and/or information coming from configuration.Preferably, the GGSN uses the IP address of the Packet Data Protocol(PDP) context as source address.

In a particularly preferred embodiment, the application level optionincludes a complete Session Initiation Protocol (SIP) message. TheGateway GPRS Support Node GGSN just has to create the IP/UDP (UserDatagram protocol) header, and to forward the message to the SIP proxy.The creation of the IP/UDP header is made by using information sent inan optional encapsulated application level message information element(for details, see the description related to FIG. 4), and/or informationcoring from the PDP context (e.g. PDP type indication if IPv4 or IPv6should be used; source address is the UE IP address) and/or informationcoming from a configuration (e.g. a destination address may be derivedfrom logical name).

If the application level option indicated that the GGSN should send theCreate PDP Context Response only when the application server response isreceived, the GGSN will start a timer to wait for answer. If a replyfrom the application server is received before the timer expires (step5), this reply or part of it is copied into the application level optioninformation element (IE) of the Create PDP Context Response. If no replyis received before the timer expires, Create PDP Context Response isseat with an indication “server not answering”.

If the application level option indicated that the GGSN should send theCreate PDP Context Response immediately, step 5 is omitted and the GGSNsends a Create PDP Context Response. The reply from the server willnaturally be sent to the IP address of the mobile terminal UE and becarried over to the PDP context as normal IP traffic.

In step 6, the GGSN sends a Create PDP Context Response, containing anindication that the application level option has been understood. Thisindication may be a new application level option containing informationreturned by the application server, an indication that the encapsulatedapplication level message has been successfully forwarded (e.g. cause“application level option successful”), or an error indication (e.g.“unknown logical name”; “unreachable destination address”; “invalidapplication level option format”; “server not answering”). Thisindication is coded as a new optional information element IE.

In step 7, the SGSN sends the Activate PDP Context Accept containing thesame indication received from the GGSN. The SGSN shall not interpretthis indication, but only copy the indication received in the Create PDPContext Response into the Activate PDP Context Accept message.

When receiving the Activate PDP Context Accept, the mobile terminal UEinforms its application process that the PDP context activation wassuccessful and provides the indication to the application process. Asmentioned earlier, this indication may be an application level optioncontaining information returned by the application server, or anapplication level cause indicating success or failure.

This indication is needed in order to support backward compatibility.The reason is that a mobile terminal UE cannot know if a network (i.e.both SGSN and GGSN) supports the feature as proposed according to thepresent invention. If the SGSN does not support the feature, the newoptional information element IE as proposed will not be forwarded to theGGSN. Therefore, the GGSN will behave normally and not send back anyindication to the SGSN about the application level. The SGSN is notsending any indication to the mobile terminal UE. Hence, the mobileterminal UE will also not pass any indication to the applicationprocess. The application will then know it has to resend its applicationas normal traffic (e.g. a IP/UDP/SIP packet over the established PDPcontext).

If the GGSN does not support the proposed functionality, it ignores theunknown optional information element IE, and correspondingly does notreturn any indication to the SGSN. The SGSN is not sending anyindication to the mobile terminal UE. Thus, the mobile terminal UE willnot pass any indication to the application process. The application willthen know it has to resend its application as normal traffic (e.g. aIP/UDP/SIP packet over the established PDP context).

Therefore, according to the above, if the SGSN or the GGSN does notsupport the proposed functionality, the UE and the application willbehave as currently, even if the benefit of the proposed functionalityis obviously lost. However, this kind of compatibility is an advantageof the present invention.

Other alternative implementations are possible such as having a full IPpacket embedded in the session management (SM) signaling in the optionalinformation element IE which would be good for the IP security protocol(IPsec). It should be noted that this solution would work in theActivate PDP Context Request message only if a static address is used,as the mobile terminal UE would not yet know its address. However, thisalternative implementation can be used also with a dynamic address inall the other session management (SM) messages (e.g. Activate PDPContext Response; Activate Secondary PDP Context Request; Modify PDPContext Request). Another option is to have only an Extensible MarkupLanguage (XML) extension carried in the application level optioninformation element between the mobile terminal UE and the GGSN that theGGSN will always forward to an application server by using apre-configured protocol (e.g. the Session Initiation Protocol). The GGSNmay also add an extension containing other information known about theuser (e.g. a user identity such as MSISDN; Charging ID; APN used; IPaddress allocated; etc.).

Encapsulated Application Level Message

As a preferred embodiment of the present invention, it is proposed tochange all session management (SM) messages by adding the new optionalinformation element (IE).

In the following, the list of the concerned session management (SM)messages is given:

-   -   Activate PDP Context Request    -   Activate PDP Context Accept    -   Activate PDP Context Reject    -   Activate Secondary PDP Context Request    -   Activate Secondary PDP Context Accept    -   Activate Secondary PDP Context Reject    -   Request PDP Context Activation    -   Request PDP Context Activation Reject    -   Modify PDP Context Request    -   Modify PDP Context Accept    -   Modify PDP Context Reject    -   Deactivate PDP Context Request    -   Deactivate PDP Context Accept

Specified below is the format of the “Activate PDP Context Request”according to the present invention. That is, specified are the changesto the existing knowledge as proposed by the present invention as anembodiment thereof. Thus, an example of the format of the newinformation element according to the present invention is presented:

Activate PDP Context Request

This message is sent by the UE to the network to request activation of aPDP context.

See table below.

Message type: ACTIVATE PDP CONTEXT REQUEST Significance: globalDirection: UE to network

Table ACTIVATE PDP CONTEXT REQUEST Message Content

Information IEI Element Type/Reference Presence Format Length ProtocolProtocol M V ½ discriminator discriminator 10.2 Transaction TransactionM V ½- 3/2 identifier identifier 10.3.2 Activate PDP Message type M V 1Context Request 10.4 message identity Requested NSAPI Network service MV 1 access point identifier 10.5.6.2 Requested LLC SAPI LLC serviceaccess M V 1 point identifier 10.5.6.9 Requested QoS Quality of serviceM LV 12  10.5.6.5 Requested PDP address Packet data M LV  3-19 protocoladdress 10.5.6.4 28 Access point name Access point name O TLV  3-10210.5.6.1 27 Protocol Protocol O TLV  3-253 configuration configurationoptions options 10.5.6.3 Encapsulated Encapsulated O TLV   3-1025application level application level message message

The new information element IE as proposed by the present invention ismarked in bold.

Description of the Encapsulated Application Level Message

The purpose of the encapsulated application level message informationelement is to carry application specific information in sessionmanagement (SM) messages, and to indicate to the GGSN which genericprocedure to use.

The encapsulated application level message is a type 4 informationelement with a minimum length of 3 octets. The maximum length for theinformation element IE is 1025 octets. It is to be noted that theinformation element IE length restriction is due to the maximum lengththat can be encoded by using 10 bits.

The encapsulated application level message_information element is codedas shown in FIG. 4.

Below, the behavior of the Gateway GPRS Support Node GGSN is describedin more detail.

When the Gateway GPRS Support Node GGSN receives a session management(SM) message with an encapsulated application level message, it willfirst check:

1) Sending Option Conditions

This field indicates the sending of the application level message:

-   -   “if the PDP context is accepted”, in which case the Gateway GPRS        Support Node GGSN sends the application level message as soon as        the Packet Data Protocol PDP context is accepted;    -   “if the Packet Data Protocol PDP context creation or        modification is accepted with the Quality-of-Service (QoS)        requested”; in which case the Gateway GPRS Support Node GGSN        sends the application level message only if the        Quality-of-Service (QoS) requested by the mobile terminal UE was        accepted unchanged (it is remarked that this may require a new        indication from the Serving GPRS Support Node SGSN to indicate        what was the Quality-of-Service QoS requested by the mobile        terminal UE). If the Quality-of-Service (QoS) was not accepted        as such, the application level option is ignored (the mobile        terminal UE will detect the change and perform needed action        such as sending the appropriate application level message).        2) Response Option Conditions

This field indicates response options to the session management (SM)message:

-   -   “immediately”; in which case the Gateway GPRS Support Node GGSN        sends the session management (SM) response message immediately        (but it may still wait for some other signaling such as RADIUS        if applicable);    -   “only when application message response is received”; the        Gateway GPRS Support Node GGSN will prepare the session        management (SM) response, but wait to receive the response from        the application server. Based on the response of the application        server, the Gateway GPRS Support Node GGSN will generate an        encapsulated application level message which it will include in        its own session management (SM) response. For example, this        involves        -   reading the User Datagram Protocol (UDP) port and copying in            appropriate encapsulated application level message field;        -   stripping away IP/UDP header;        -   including the content of the User Datagram Protocol (UDP)            packet in the encapsulated application level message content            field; as well as        -   using IP/UDP header info to properly set Port number to be            used for sending.

Note that this field is applicable only for a session management (SM)request message and not for a response message.

3) The Protocol to be Used for Sending

In case of:

-   -   IPv4/UDP: The Gateway GPRS Support Node GGSN will include the        encapsulated application level message content field in a        IPv4/UDP packet;    -   IPv6/UDP: The Gateway GPRS Support Node GGSN will include the        encapsulated application level message content field in a        IPv6/UDP packet;    -   IPv4/TCP: The Gateway GPRS Support Node GGSN will include the        encapsulated application level message content field in a        IPv4/TCP (Transfer Control Protocol) packet; and    -   IPv6/TCP: The Gateway GPRS Support Node GGSN will include the        encapsulated application level message content field in a        IPv6/TCP packet.

It is remarked that it is one alternative to omit this field, so thatthe User Datagram Protocol (UDP) is always used and the Packet DataProtocol (PDP) type indicates IPv6 (Internet Protocol version 6) or IPv4(Internet Protocol version 4).

Another alternative is to have a more detailed indication such as thatthe Gateway GPRS Support Node GGSN will include the encapsulatedapplication level message content field in a Session Initiation Protocol(SIP) register message over IPv6/UDP.

Still another alternative is that the address type indicates the lowerlevel protocol: IPv4 or IPv6.

It is remarked that other protocols may be indicated such as L2TP/PPP(Layer 2 Transfer Protocol—Point to Point Protocol).

4) Port Number to be Used for Sending

The use of this port is to limit the need of a Gateway GPRS Support NodeGGSN to know about the application protocol. So this field indicates tothe Gateway GPRS Support Node GGSN if a fixed User Datagram Protocol(UDP) port is to be used (including the value) or if the User DatagramProtocol (UDP) port needs to be selected from a certain range.

5) Setting the Traffic Flow Template (TFT) Condition

If the mobile terminal UE indicates the destination address with alogical name, it cannot restrict the traffic for this Packet DataProtocol (PDP) context only fog this destination address. Thus, thisfield is used to indicate that only the traffic coming from thedestination address (which is to be derived from the Gateway GPRSSupport Node GGSN based on the logical name) on this Packet DataProtocol (PDP) context shall be allowed. It is remarked that the PacketData Protocol (PDP) context signaling would be one use case for thisfeature. This field can have the contents:

-   -   Destination address type—This indicates if the address is a        logical name, an IPv6 or IPv4 address; and    -   Application level option content—This field includes the actual        content that the Gateway GPRS Support Node GGSN relays from the        session management (SM) message to the application level message        it generates. In one preferred embodiment, this is a Session        Initiation Protocol (SIP) message.

The invention is not limited to this format of encapsulated applicationlevel message. A simple implementation may be preferred where the GGSNbehavior is simplified. For example, the GGSN may always forward theapplication message if the PDP context is accepted; it may always wait acertain time for an answer from the application server.

Besides, it is remarked that in the case where a mobile terminal UE isconnected to a laptop, the mobile terminal UE could perform a similarfunction as the Gateway GPRS Support Node GGSN. In this case, somefields which are not applicable should be ignored.

Also the format may be different in uplink and downlink direction. Forexample, to simplify the behavior of the mobile terminal UE, the GGSNmay still include the full message (i.e. including IP header) receivedby the application server in the response message as described above.But for the uplink, it may be more beneficial to not include the IPheader, as the mobile terminal UE may not yet know its dynamic addressat the time of sending the session management (SM) request and it maynot know the real IP address of the application server.

It should be noted that this feature is specially advantageous for thenetwork requested PDP context activation. This procedure is triggered byan IP packet arriving at the GGSN. Currently, the packet is stored inthe GGSN and can be delivered to the mobile terminal UE over a normalPDP context only after a lot of signaling (including PDP contextactivation). One of the problems is that when the mobile terminal UEreceives the Request PDP Context Activation, it does not know whichmessage has triggered the application. Thus, the mobile terminal UE hastoo little information to decide whether to activate a new PDP contextor not. However, according to the present invention, the full IP messagecould be sent to the mobile terminal UE. Therefore, in addition tosaving round trip on the radio, it also provides more information to themobile terminal UE. That is, e.g. the GGSN encapsulates the messagereceived by the server in the message called PDU notification sent tothe SGSN. The SGSN copies encapsulated information in the message called“Request PDP Context Activation” and sends it to mobile terminal UE.

It should be noted that the amount of encapsulated application levelmessage should be recorded in the charging record.

What is described above is a method of carrying an application levelmessage encapsulated inside a signaling message of an access network,said method comprising the steps of: receiving an application levelmessage from a sender application process to an access network signalingprocess; adapting said application level message and encapsulating it ina signaling message of an access network; and delivering saidencapsulated application level message to a receiver application processby transmitting said signaling message, wherein said encapsulatedapplication level message is transparent to the means of said accessnetwork transmitting said signaling message.

Although it is described above what are the preferred embodiments of thepresent invention, it is apparent to those skilled in the art thatvarious modifications are possible without departing from the scope ofthe present invention as defined by the appended claims.

1. A method, comprising: receiving an application level message from asender application process to an access network signaling process;encapsulating said application level message in a signaling message ofan access network; and initiating transmission of said encapsulatedapplication level message to a network node by transmitting saidsignaling message, wherein said encapsulated application level messageis transparent to a device of said access network transmitting saidsignaling message, said application level message comprises anindication of conditions to deliver the application message, and saidapplication level message is sent after a packet data protocol contextis accepted by a gateway, said encapsulated application level messagecomprises a complete session initiation protocol message.
 2. A methodaccording to claim 1, wherein said sender application process isperformed in a mobile terminal coupled to said access network.
 3. Amethod according to claim 1, wherein said sender application process isperformed in an application server configured to provide a correspondingapplication.
 4. A method according to claim 1, wherein said indicationcomprises an address of an application server, said address being one ofthe group comprising a logical name, an internet protocol address, and aport number.
 5. A method according to claim 1, wherein said indicationcomprises an indication of whether to deliver said signaling messagewhen the quality-of-service changes.
 6. A method according to claim 1,wherein said method is implemented in a call establishment procedure fora voice over the internet protocol.
 7. A method according to claim 1,wherein said encapsulated application level message is included in anactivation request within a packet data protocol context signaling.
 8. Amethod according to claim 3, wherein said application server is one ofthe group comprising a proxy call state control function, a push proxyserver, and an instant message server.
 9. A method according to claim 7,wherein a session initiation protocol signaling, a resource reservationprotocol signaling, or a point to point protocol signaling is embeddedinto said packet data protocol context signaling.
 10. A method accordingto claim 1, wherein said complete session initiation protocol message issent by a gateway general packet radio system support node to a sessioninitiation protocol proxy, wherein said gateway general packet radiosystem support node is configured to create an internet protocol/userdatagram protocol header and to send said complete session initiationprotocol message to a session initiation protocol proxy.
 11. A methodaccording to claim 10, wherein said header is created by usinginformation sent in an optional application level message informationelement.
 12. A method according to claim 10, wherein said header iscreated by using information coming from said packet data protocolcontext signaling.
 13. A method according to claim 10, wherein saidheader is created by using information coming from a configurationprocess.
 14. A method according to claim 7, wherein said encapsulatedapplication level message indicates that a gateway general packet radiosystem support node shall send a context response message only when aresponse is received, as a reaction to which said gateway general packetradio system support node starts a timer to wait for an answer, andwherein a reply before the expiration of said timer is copied as a newencapsulated application level message in said context response message,and in case of no reply before the expiration of said timer, anindication that an answer was not received is copied as a newencapsulated application level message in said context response message.15. A method according to claim 7, wherein said encapsulated applicationlevel message indicates that a gateway general packet radio systemsupport node is configured to send a context response messageimmediately, as a reaction to which said gateway general packet radiosystem support node sends a context response message immediately,whereas a response of said receiver application process is returned tosaid sender application process in a non-encapsulated manner as normaltraffic.
 16. An apparatus, comprising: receiving means for receiving anapplication level message from a sender application process to an accessnetwork signaling process; encapsulating means for encapsulating saidapplication level message in a signaling message of an access network,wherein said encapsulated application level message comprises a completesession initiation protocol message; and transmitting means forinitiating transmission of said encapsulated application level messageto a network node, wherein said encapsulated application level messageis transparent to a device of said access network transmitting saidsignaling message, said application level message comprises anindication of conditions to deliver the application message, and saidapplication level message is sent after a packet data protocol contextis accepted by a gateway.
 17. An apparatus according to 16, wherein aserver is configured to perform said sender application process.
 18. Anapparatus according to claim 17, wherein said server is one of the groupcomprising a proxy call state control function, a push proxy servermeans, and an instant message server.
 19. A method, comprising:receiving an encapsulated application level message, wherein saidencapsulated application level message comprises a complete sessioninitiation protocol message; extracting content from the encapsulatedapplication level message; interpreting, from the extracted content ofthe encapsulated application level message, an address and conditions tosend the extracted content of the encapsulated application levelmessage; and initiate sending of the extracted content to an applicationserver in accordance with a packet data protocol context and one or moreof the interpreted address and an access point name configuration. 20.The method of claim 19, wherein the conditions to send the encapsulatedapplication level message comprise when a packet data protocol contextis accepted or when a packet data protocol context is accepted with adesired quality of service.
 21. The method of claim 19, wherein, whenthe address is indicated as a logical name, the logical name is resolvedfrom the access point name configuration or by querying a directory nameservice system.
 22. The method of claim 19, wherein the encapsulatedapplication level message is included in an activation request within apacket data protocol context signaling.
 23. The method of claim 22,wherein a session initiation protocol signaling, a resource reservationprotocol signaling, or a point to point protocol signaling is embeddedinto said packet data protocol context signaling.
 24. The method ofclaim 19, further comprising: creating an internet protocol/userdatagram protocol header; and forwarding the complete session initiationprotocol message to a session initiation protocol proxy.
 25. Anapparatus, comprising: a processer; and a memory including computerprogram code; the memory and the computer program code configured to.with the processor, cause the apparatus to perform at least thefollowing, receive an encapsulated application level message, extractcontent from the encapsulated application level message, wherein saidencapsulated application level message comprises a complete sessioninitiation protocol message, interpret, from the extracted content ofthe encapsulated application level message, an address and conditions tosend the extracted content of the encapsulated application levelmessage, and initiate sending of the extracted content to an applicationserver in accordance with a packet data protocol context and one or moreof the interpreted address and an access point name configuration. 26.The apparatus of claim 25, wherein the conditions to send theencapsulated application level message comprise when a packet dataprotocol context is accepted or when a packet data protocol context isaccepted with a desired quality of service.
 27. The apparatus of claim25, wherein, when the address is indicated as a logical name, theapparatus is configured to resolve the logical name from the accesspoint name configuration or by querying a directory name service system.28. The apparatus of claim 25, wherein the apparatus is configured toinclude the encapsulated application level message in an activationrequest within a packet data protocol context signaling.
 29. Theapparatus of claim 28, wherein the apparatus is configured to embed asession initiation protocol signaling, a resource reservation protocolsignaling, or a point to point protocol signaling into said packet dataprotocol context signaling.
 30. The apparatus of claim 25 wherein theprocessor is further configured to create an internet protocol/userdatagram protocol header, and initiate sending of the complete sessioninitiation protocol message to a session initiation protocol proxy. 31.An apparatus, comprising: a processor; and a memory including computerprogram code; the memory and the computer program code configured to,with the processor, cause the apparatus to perform at least thefollowing, receive an application level message from a senderapplication process to an access network signaling process, encapsulatesaid application level message in a signaling message of an accessnetwork, wherein said encapsulated application level message comprises acomplete session initiation protocol message, and initiate transmissionof said encapsulated application level message to a network node,wherein said encapsulated application level message is transparent todevice of said access network transmitting said signaling message, saidapplication level message comprises an indication of conditions todeliver the application message, and said application level message issent after a packet data protocol context is accepted by a gateway. 32.An apparatus according to claim 31, wherein said apparatus comprises amobile terminal.
 33. An apparatus according to claim 31, wherein saidindication comprises an address of an application server, said addressbeing one of the group comprising a logical name, an internet protocoladdress, and a port number.
 34. An apparatus according to claim 31,wherein said indication comprises an indication of whether to deliversaid signaling message when the quality-of-service changes.
 35. Anapparatus according to claim 31, wherein the apparatus is configured totransmit the encapsulated application level message as part of a callestablishment procedure for a voice over the internet protocol.
 36. Anapparatus according to claim 31, wherein the apparatus is configured toinclude said encapsulated application level message in an activationrequest within a packet data protocol context signaling.
 37. Anapparatus according to claim 36, wherein said apparatus is configured toembed a session initiation protocol signaling, a resource reservationprotocol signaling, or a point to point protocol signaling into saidpacket data protocol context signaling.
 38. An apparatus according toclaim 36, wherein said encapsulated application level message indicatesthat a gateway general packet radio system support node is configured tosend a context response message only when a response is received, as areaction to which said gateway general packet radio system support nodestarts a timer to wait for an answer, and wherein a reply before theexpiration of said timer is copied as a new encapsulated applicationlevel message in said context response message, and in case of no replybefore the expiration of said timer, an indication that an answer wasnot received is copied as a new encapsulated application level messagein said context response message.
 39. A system, comprising: a networknode; and a user equipment comprising a receiver configured to receivean application level message from a sender application process to anaccess network signaling process, a processor configured to encapsulatesaid application level message in a signaling message of an accessnetwork, wherein said encapsulated application level message comprises acomplete session initiation protocol message, and a transmitterconfigured to transmit said encapsulated application level message tothe network node, wherein the network node comprises, a receiverconfigured to receive the encapsulated application level message, aprocessor configured to interpret, from the encapsulated applicationlevel message, an address and conditions to send the encapsulatedapplication level message, and extract content from the encapsulatedapplication level message, and a transmitter configured to forward theextracted content to an application server in accordance with one ormore of the interpreted address, a packet data protocol context and anaccess point name configuration, wherein said encapsulated applicationlevel message is transparent to device of said access networktransmitting said signaling message, and said application level messagecomprises an indication of conditions to deliver the applicationmessage.